第九日：知識地基大檢修，Context Engineering 復盤

今天是鐵人賽第九天。前八天，我們一路從「AI 巨輪下的恐懼」寫到「API 工地開張」，該踩的坑踩了不少，該冒的煙也冒了不少。今天暫時放下手中的鋤頭(我怎麼老是在休息)，改戴上安全帽與放大鏡，來一場知識地基的檢修。因為我很清楚：如果基本理論沒打穩，後面再蓋的摩天大樓遲早會傾斜。這一天的重點，就是從 Context Engineering 的理論出發，結合前面八天的實戰，復盤哪些地方需要調整與優化(其實是李宏毅開課了)，先來補齊基礎知識。

一、Context Engineering 的本質：不是神奇咒語，而是施工藍圖

李宏毅老師一開始就提醒：「這堂課沒有訓練任何模型，訓練的其實是人」。這句話點破了核心 —— 我們能掌控的不是模型，而是輸入給模型的「脈絡」。

傳統的 Prompt Engineering，常常像是魔法咒語：

• 加一句「Let’s think step by step」，模型就好像突然變聰明了。
• 多唸幾遍「ways ways ways…」，它就回你一大串。

但這些「神奇咒語」隨著模型進化已經逐漸失效。原因很簡單：現代模型應該「隨時全力思考」，不該靠咒語來開關腦袋。

因此，Context Engineering 更像工程學(這個終於給我比較像工程師的感覺)：

• 我們要規劃整個場景，選擇要給模型什麼、不給什麼。
• 把需要的資訊丟進去，不需要的清出來。
• 如果 prompt 是一塊拼圖，那 context 就是一整副拼圖的邊框，決定模型能看見什麼世界。

二、Context 的組成：不只是 Prompt

從課程裡，整理出一個「Context 七件套」：

1. User Prompt：使用者需求、細節、限制條件。
   • 例：「請幫我生成 Go 語言 API skeleton，要符合 RESTful，並加上 quota 限制。」
2. 範例（Examples）：In-context learning，透過例子引導模型。
3. System Prompt：規範角色、風格、限制（例如 Claude 的 system prompt 長達 2500 字）。
4. 對話歷史（Dialogue History）：短期記憶。
5. 長期記憶（Memory）：例如我們第 6～8 天的需求文件、API spec，就屬於可長期儲存的 context。
6. 外部資訊（RAG）：文件、資料庫、搜尋引擎。
7. 工具與推理（Tool Use + Reasoning）：AI 用 API、寫 code、操控電腦，並在腦內演算。

這讓我重新審視前幾天的做法。到目前為止，我大多是把需求丟進去，附上範例和回饋，屬於「User Prompt + Examples + Dialogue History」的組合。
但隨著專案越來越大，這樣做就會出現三大問題：

• 資訊爆炸：需求文件、API 規格、測試樣例全都丟進去，結果 context 爆炸，模型開始「Lost in the Middle」。
• 雜訊過多：沒有篩選或壓縮，模型反而被干擾。
• 缺少長期記憶：每次新開一輪，前面八天的血淚史它完全忘光。

三、Context Engineering 的方法論：三招打天下

文件中提到三大招數：挑選（Select）、壓縮（Compress）、多 Agent（Multi-Agent）。

1. 挑選（Select）

• 不要什麼都丟。
• 適當用 RAG，只把相關的文件片段送進模型。
• 甚至可以透過小模型做 rerank，先挑出 3 個最相關的段落，再交給大模型。

👉 復盤：我們在第 7～8 天把整份 requirement.md 丟進去，雖然有效，但成本高、效率低。接下來應該拆成小段，讓模型只看與當前 API 有關的部分。

2. 壓縮（Compress）

• 對過去的對話、操作記錄做摘要。
• 把細碎的 log 壓成「完成了 A，結果是 B」這樣的結論，再送進 context。
• 長期歷史可放到外部存儲，必要時用 RAG 拉回來。

👉 復盤：我們的 0921、0922.log 其實就是原始聊天紀錄，直接餵進模型會浪費 token。應該先人工/程式化做摘要，再丟。

3. 多 Agent（Multi-Agent）

• 單一 Agent 會被「Context 過載」壓垮。
• 多 Agent 拆工，像是 ChatDev 那樣，一個負責 DB schema，一個負責 API 定義，最後由 Lead Agent 整合。

👉 復盤：到目前為止，都是「單兵作戰」：我 + Codex。未來可以試「多 Agent 分工」，例如讓一個專門做測試生成，另一個專門檢查安全性。

四、Context 的陷阱：長 ≠ 好

文件特別強調：「能讀百萬 token，不代表能懂百萬 token」。這提醒我前幾天遇到的問題 —— 當我把所有 API spec、entities、us-001 全部丟進去，模型反而回得四不像。

這其實就是 Context Rot 或 Lost in the Middle：

• 模型會特別記得開頭與結尾，中間的東西被「遺忘」。
• 當輸入超過一定長度，正確率反而下降。

👉 改進策略：

• 短上下文：單次輸入控制在合理長度。
• 關鍵資訊固定位置：例如每次把 DB schema 放在最前面，API spec 放在最後面。
• 過期資訊要丟棄：不要一直把舊 log 疊加進去。

五、AI 工地與 Context 的對照

把 Context Engineering 理論套回我們的專案，可以得到一個有趣的對照表：

六、未來調整方向：從「瞎丟」到「精煉」

經過今天的知識復盤，我決定未來幾天要做這些改進：

1. 建立 System Prompt 範本：

   • 指定：程式語言、框架、錯誤處理風格、測試要求。
   • 讓輸出更一致，不用每次靠人工糾正。

2. 需求卡片化 + Context 切片：

   • 每個小需求獨立一段 context，不要一次塞整份 spec。

3. Log 摘要化：

   • 自動產生「今日開發進度摘要」，取代原始 log，減少 token 浪費。

4. 導入 RAG：

   • 用簡單的向量 DB，把 entities、API spec 存進去，查詢時才拉進 context。

5. 嘗試 Multi-Agent：

   • 例如一個測試 Agent 專門生成單元測試，另一個安全 Agent 專門檢查 SQL/權限。

七、今日小結：知識地基打穩，工地才蓋得高

今天的第九天日誌不像前幾天有一堆程式碼，而是把鏡頭拉遠，來看大局：

• Context 是 AI 工地的地基。
• 不懂 Context Engineering，只會一直「亂丟 prompt」，最後不是成本爆炸，就是結果四不像。
• 復盤讓我意識到：我們前幾天的流程雖然有產出，但還有很多改進空間。

一句話收尾：
👉 第九天，我不是在搬磚，而是在檢查地基。
因為我知道，明天開始要蓋的樓層會越來越高，如果不先修正，最後大樓會變成比薩斜塔。